1. Field of the Invention
The present invention relates to an information processing apparatus in which a plurality of types of printer drivers and a plurality of types of graphics units run, a control method therefor, and a program.
2. Description of the Related Art
An application on a host computer prints an image or text from a printer by generally using an arrangement as shown in FIG. 1.
More specifically, an application 101 on a host computer 3000 passes graphics data to a graphics engine 103. The graphics engine 103 processes the graphics data and passes it to a printer driver 104. The printer driver 104 generates print data (e.g., PDL: Page Description Language) to a printer 1500. The print data is stored in a spooler 105 and then sent to the printer 1500.
In particular, the graphics engine 103 converts the resolution of graphics data created by the application 101, and processes graphics data by a simulation process or the like in accordance with the performance of the printer driver 104. The graphics engine 103 allows the application 101 and printer driver 104 to operate independently of each other. The graphics engine 103 is generally provided as part of an OS (Operating System) 102.
The number of graphics engines 103 is not always one, but may be two or more.
For example, Microsoft held a hardware engineering conference WinHEC 2005 in Seattle, U.S.A., in 2005. At this conference, Microsoft announced that a new Microsoft OS (Windows® Vista) supports two graphics engines (GDI 202 and WPF 212) as shown in FIG. 2. (http://www.microsoft.com/whdc/device/print/default.msp×(Advances in Windows® Printing: TWPR05001_WinHEC05.ppt)). The WPF stands for Windows® Presentation Foundation.
A conventional Microsoft printing system utilizes a graphics engine “GDI” from an application using an API called a Win32 API, and creates print data from graphics data by a printer driver called from the GDI. This print process sequence is called a GDI print path.
The API stands for Application Programming Interface. The GDI stands for Graphic Device Interface. An application using the Win32 API will be referred to as a Win32 application 201. A printer driver called from the GDI will be referred to as a GDI printer driver 203.
According to Windows® Vista, a new print process sequence called an XPS print path is added to the conventional GDI print path. The XPS print path is a print process sequence to convert XPS graphics data into print data by the printer driver using a graphics engine “WPF” from an application using a WinFx API.
The XPS stands for XML Paper Specification. An application using the WinFx API will be referred to as a WinFx application 211. A printer driver which processes XPS graphics data will be referred to as an XPS printer driver 213.
These graphics engines, i.e., GDI 202 and WPF 212 can cooperate with each other. With this cooperation, the Win32 application 201 can pass graphics data to the XPS printer driver 213, and the WinFx application 211 can pass graphics data to the GDI printer driver 203.
The cooperative mechanism of the two graphics engines in Windows® Vista will be explained with reference to FIG. 3.
A print process sequence (1) represents a conventional GDI print path. Graphics data passed from the Win32 application 201 is stored as an EMF (Enhanced Metafile) spool file 301 in the GDI 202. Then, the GDI printer driver 203 converts the EMF spool file 301 into print data.
A print process sequence (4) represents an XPS print path added in Windows® Vista. Graphics data passed from the WinFx application 211 is stored as an XPS spool file 311 in the WPF 212. Then, the XPS printer driver 213 converts the XPS spool file 311 into print data.
A print process sequence (3) represents a print process sequence when the GDI printer driver 203 prints graphics data from the WinFx application 211. Graphics data passed from the WinFx application 211 is converted into EMF graphics data by an XPS→GDI conversion module 312 via the WPF 212, and stored as the EMF spool file 301. Then, the GDI printer driver 203 converts the EMF spool file 301 into print data.
A print process sequence (2) represents a process sequence when the XPS printer driver 213 prints graphics data from the Win32 application 201. Graphics data passed from the Win32 application 201 is converted into XPS graphics data by a GDI→XPS conversion module 302 via the GDI 202, and stored as the XPS spool file 311. Then, the XPS printer driver 213 converts the XPS spool file 311 into print data.
In Windows® Vista, two graphics engines coexist and cooperate with each other, so the four print process sequences are conceivable. Either the GDI printer driver 203 or XPS printer driver 213 is prepared as a printer driver for a printer and can cope with print processes from both the Win32 application 201 and WinFx application 211.
There is proposed a print support technique of acquiring PDL information from a printer, selecting a proper driver, and if no proper driver exists, uploading it from a device, installing it, and printing by the installed driver (Japanese Patent Laid-Open No. 2004-021460).
The XPS and EMF formats are different. The print quality, print function, and print speed may degrade if a print process is executed using a print process sequence of converting graphics data, like the print process sequences (2) and (3) in FIG. 3.
In terms of the print function, for example, logical operation-containing graphics data supported by the EMF format is not supported by the XPS format in the print process sequence (2). The GDI→XPS conversion module 302 deletes logical operation information when converting EMF graphics data into XPS one. The XPS printer driver 213 receives graphics data having no logical operation information. When the user outputs the result created using the Win32 application 201 from the XPS printer driver 213, he may not obtain any intended output result.
To the contrary, advanced graphics graphics data supported by the XPS format is not supported by the EMF format in the print process sequence (3). The XPS→GDI conversion module 312 performs local bitmapping “Flattering” when converting XPS graphics data into GDI one. In this case, graphics data is converted into bitmap data, and the GDI printer driver 203 cannot determine the original object attribute, failing to obtain any user-intended output result.
In terms of the print function, for example, electronic signature information supported by the XPS format is not supported by the EMF format in the print process sequence (3). A process supported by the EMF format to directly notify the GDI printer driver 203 of information from an application is not supported by the XPS format in the print process sequence (2). For this reason, even if an application uses functions applicable to the print process sequences (1) and (4), these functions cannot be implemented in the print process sequences (2) and (3).
The print speeds in the print process sequences (2) and (3) are lower than those in the print process sequences (1) and (4) because of processes such as GDI→XPS conversion and XPS→GDI conversion.
It is, therefore, desirable to avoid the print process sequences (2) and (3). Even if both the XPS printer driver and GDI printer driver are registered for the same printer, the graphics engine in Windows® Vista does not dynamically switch to give priority to the print process sequence (1) or (4). In principle, the user does not recognize that the application is a Win32 or WinFx application or that there are four print process sequences. It is difficult to avoid the print process sequences (2) and (3).
Print setting information has print setting data in a data structure called the DevMode structure on the GDI print path, but has it in an XML data structure called PrintTicket on the XPS print path. Conversion from GDI to XPS or from XPS to GDI requires conversion from DevMode into PrintTicket or from PrintTicket into DevMode. Similar to graphics data, the DevMode expressible range and PrintTicket expressible range are different from each other. This process is done not automatically by the operating system but by the printer driver itself using an expanded architecture. No data is omitted, unlike graphics, if an IHV which creates a printer driver appropriately prepares a conversion process.